Skip to content

Drop coreapi support for DRF 3.17 #9583

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

Drop coreapi support for DRF 3.17 #9583

wants to merge 4 commits into from
+0 −2

Conversation

TGoddessana
Copy link
Contributor

Description

refs #8453

As discussed in #8453, we are deprecating the coreapi for drf 3.17.

I read the discussion in detail, and I'm wondering if it was decided to “leave all schema generation logic in the library that generates the schema (drf-spectacular), and drf will not be involved in schema generation” (drf-spectacular will be part of drf?) The comments in the linked discussion say that...

Yes. The idea would be to leave (just) the extension points in place, as they are.

@auvipy auvipy self-requested a review December 18, 2024 10:15
@drjaska drjaska mentioned this pull request Feb 1, 2025
Open
@TGoddessana TGoddessana force-pushed the drop-coreapi-support branch from 951c960 to e8c0236 Compare March 15, 2025 17:05
@TGoddessana
Copy link
Contributor Author

TGoddessana commented Mar 21, 2025 •
edited
Loading

Question while working with PR.

The documentation says: “Support for generating default schemas will be moved to a separate package and then removed”. For this PR, should we remove coreapi and everything related to it, or all code related to the whole rest_framework/schemas/ package?

If you need to remove everything related to schemas from the Rest Framework, you can remove most of the code, tests, etc. in /schemas. What do you team think about this?

@TGoddessana
Copy link
Contributor Author

@auvipy I'm sorry if the tags are annoying. But this is the only place we can make design decisions about PR, and I'd love to hear your thoughts on what I should do..

@auvipy
Copy link
Collaborator

auvipy commented Apr 16, 2025

yes please fix the merge conflicts as we have to remove it

@TGoddessana TGoddessana force-pushed the drop-coreapi-support branch from 14956c8 to d43bae2 Compare May 3, 2025 14:31
@johnthagen johnthagen mentioned this pull request May 22, 2025
Open
@TGoddessana
Copy link
Contributor Author

I guess this is where we need to make a decision on where we stop supporting it... For example, should we remove all schema-related references in rest_framework.settings since schema generation will stop?

The documentation certainly mentions that we will be removing API documentation, but I'm confused if removing all code like schemas.utils or renderers.CoreJSONRenderer is included in this scope.

@TGoddessana
Copy link
Contributor Author

image

For example, the APIView class defaults to the DefaultSchema() class that was included in the schema package.

If we were to remove schema generation, would it be right to remove these codes as well?

@browniebroke browniebroke added this to the 3.17 milestone Jul 6, 2025
@browniebroke
Copy link
Collaborator

That's a big one! I didn't expect to see some much code deleted, but I can see there was a lot of tests...

If we were to remove schema generation, would it be right to remove these codes as well?

Would be interesting to see what drf-spectacular or drf-yasg are using to hook into DRF, and make sure we don't break their integration point. Might be a good idea to coordinate this with them.

@TGoddessana
Copy link
Contributor Author

Alright, I think it's best to restart the PR, so I've reverted the commit. Both packages directly depend on this part of rest_framework. Let's see this..

(Some parts of this content were generated using AI. :) I think it's a really useful tool for situations like this. But basically, I found and verified all the code references myself.)

drf-spectacular

Essential Components to Maintain

Component Location Type Purpose drf-spectacular Usage
ViewInspector rest_framework.schemas.inspectors Base Class Core schema inspection interface Inherited by AutoSchema class
BaseSchemaGenerator rest_framework.schemas.generators Base Class Schema generation interface Used by drf-spectacular generators
BaseEndpointEnumerator rest_framework.schemas.generators Base Class API endpoint discovery logic Extended by EndpointEnumerator
get_pk_description rest_framework.schemas.utils Utility Function Primary key field description Direct import and usage

Components Safe to Remove

Component Location Type Reason for Removal
AutoSchema (DRF's implementation) rest_framework.schemas Class Replaced by drf-spectacular's AutoSchema
CoreAPI schema generators rest_framework.schemas.coreapi Module Legacy schema format
OpenAPI 2.0 generators rest_framework.schemas.openapi Module Superseded by drf-spectacular
Schema view implementations rest_framework.schemas.views Module Custom implementations available

Critical Interfaces to Preserve

Interface Method/Attribute Required for Compatibility
ViewInspector get_operation() Method signature and base behavior
ViewInspector get_description() Method signature
ViewInspector get_summary() Method signature
BaseEndpointEnumerator get_api_endpoints() Method signature and return format
BaseEndpointEnumerator get_path_from_regex() Method signature
BaseSchemaGenerator Base interface Class structure and constructor

drf-yasg

Essential Components to Maintain

Component Location Type Purpose drf-yasg Usage
EndpointEnumerator rest_framework.schemas.generators Base Class API endpoint discovery logic Extended by custom EndpointEnumerator
SchemaGenerator rest_framework.schemas.openapi Base Class OpenAPI schema generation Used as base for drf-yasg generator
get_pk_description rest_framework.schemas.utils Utility Function Primary key field description Direct import and usage
get_pk_name rest_framework.schemas.generators Utility Function Primary key field name extraction Direct import and usage
endpoint_ordering rest_framework.schemas.generators Utility Function Endpoint sorting logic Direct import and usage
AutoSchema rest_framework.schemas Class Schema inspection interface Used internally by SwaggerAutoSchema

Components Safe to Remove

Component Location Type Reason for Removal
DRF's default OpenAPI implementation rest_framework.schemas.openapi Implementation Replaced by drf-yasg's implementation
CoreAPI schema generators rest_framework.schemas.coreapi Module Legacy schema format
Default schema view implementations rest_framework.schemas.views Module Custom implementations available

Critical Interfaces to Preserve

Interface Method/Attribute Required for Compatibility
EndpointEnumerator get_path_from_regex() Method signature and regex processing
EndpointEnumerator should_include_endpoint() Method signature for endpoint filtering
SchemaGenerator Base class structure Constructor and inheritance compatibility
AutoSchema view attribute Used by SwaggerAutoSchema._sch.view
Utility functions Import paths All utility function locations must remain stable

Key Differences from drf-spectacular

Aspect drf-yasg drf-spectacular
Base Schema Class Uses AutoSchema internally Inherits from ViewInspector
Generator Approach Extends SchemaGenerator Uses BaseSchemaGenerator
Endpoint Discovery Heavily customizes EndpointEnumerator Extends BaseEndpointEnumerator
Utility Dependencies More extensive use of DRF utilities Minimal utility usage

@TGoddessana
Copy link
Contributor Author

TGoddessana commented Sep 21, 2025 •
edited
Loading

In my view, there are two possible approaches:

  1. Remove all schema-related code and settings from DRF, requiring both packages to redefine the relevant dependency code within the schemas package. This would fully eliminate the schema generation logic, which I believe results in a cleaner overall design.

  2. Retain the dependent code as summarized above. While this would leave some legacy code in place, it would preserve compatibility.

From a maintenance perspective, I tend to favor Option 1 (removing all schema-related code). The deprecation of coreapi has been clearly noted in both the codebase and documentation for some time, and it seems more sustainable for DRF not to maintain direct dependencies on third-party packages(similar to how Django continues to evolve without holding back updates purely for compatibility with DRF.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@auvipy auvipy Awaiting requested review from auvipy

At least 2 approving reviews are required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
3.17
Development

Successfully merging this pull request may close these issues.
3 participants
@TGoddessana @auvipy @browniebroke